feat: loop mode + poetic closing (5-min EventBridge loop, haiku, "Reminds me of" suffix) - #7

tests/format.test.ts (1)

5-9: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Type the helper return value as LoopContext.

The helper builds a structural match for LoopContext but is not annotated. An added or renamed field in src/format/types.ts would not fail this test file. Annotate the return type so the tests track the interface.

♻️ Proposed annotation

+import type { LoopContext } from '../src/format/types.js';
+
-const ctx = (readings: Array<{ source: 'weather' | 'crypto'; value: string }>, date = '2026-08-09', location = 'NYC') => ({
+const ctx = (
+  readings: Array<{ source: 'weather' | 'crypto'; value: string }>,
+  date = '2026-08-09',
+  location = 'NYC',
+): LoopContext => ({
   date,
   location,
   readings,
 });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/format.test.ts` around lines 5 - 9, Annotate the return value of the
ctx helper as LoopContext so its structural object is checked against the
interface defined in the format types. Keep the existing parameters and returned
fields unchanged.

tests/db.test.ts (1)

237-240: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Also assert that the legacy row survives the second bootstrap.

The comment says the re-run "must not alter the column", but the test only counts columns. Add a check that the NULL base_message row is still present and still NULL. That pins the migration's data-preservation behavior, not only the schema shape.

♻️ Proposed additional assertion

     const colsAfter = db.prepare(`PRAGMA table_info(agent_notifications)`).all() as Array<{ name: string }>;
     expect(colsAfter.filter((c) => c.name === 'base_message')).toHaveLength(1);
+    const legacy = db
+      .prepare(`SELECT base_message FROM agent_notifications`)
+      .all() as Array<{ base_message: string | null }>;
+    expect(legacy).toHaveLength(1);
+    expect(legacy[0]?.base_message).toBeNull();

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/db.test.ts` around lines 237 - 240, Extend the second-bootstrap
assertions in the test around bootstrap(db) to query the existing legacy row and
verify it remains present with a NULL base_message value. Keep the current
single-column assertion, and ensure the added check validates data preservation
rather than only schema shape.

tests/similarity.test.ts (1)

91-111: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win

Pin the KNN-window behavior for legacy rows.

Add a test with KNN_CANDIDATES + 1 NULL rows closer than one valid row. Assert the current post-filter behavior (findNearestMatch returns null), or change the query if valid rows must remain discoverable.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/similarity.test.ts` around lines 91 - 111, Update the similarity tests
around findNearestMatch to add KNN_CANDIDATES + 1 legacy notifications with NULL
base_message values closer than a valid notification, then assert the intended
post-filter behavior: findNearestMatch returns null. If the intended contract is
to keep valid rows discoverable, instead adjust the query implementation and
assert that the valid notification is returned.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/agent/fetch.ts:242

• db.close() is called before delegating to publish(), but publish() also closes the database. Remove the extra close so the failure path doesn't depend on close() being idempotent.

    db.close();
    return publish(db, params, priorEtag, runId, now, 0, errors);

src/agent/fetch.ts:214

• If embedding succeeds but findNearestMatch throws, preVector is already populated, so the later insert loop still writes embeddings despite this catch promising to skip them. Reset it here so lookup failures follow the documented all-or-nothing RAG failure path.

  } catch (error: unknown) {
    const message = error instanceof Error ? error.message : String(error);
    errors.push(`rag: ${message}`);
    // preVector stays null — step 13's embedding insert is skipped for this tick.

README.md:59

• The implementation has no similarity-distance threshold: any eligible KNN result is appended. Saying “close enough” therefore misstates the visible behavior once the corpus contains any non-null base_message.

friendly comment drawn from today's date, weather, and crypto price, ending with a

README.md:47

• This new 5-minute default leaves the later “The daily fetch run” sentence at line 73 stale. Update that sentence to say “scheduled” (or “5-minute”) so the README does not describe two different cadences.

The deployed EventBridge schedule runs every 5 minutes by default. Use `loop-stop` to

docs/02-rehydration.md:83

• A fresh container does not recover from this condition: it immediately rehydrates the same oversized S3 snapshot and hits the same 512 MB ceiling. Recovery requires increasing ephemeral storage or pruning/replacing the persisted snapshot.

until a redeploy resurfaces a fresh container with an empty `/tmp`.

docs/superpowers/specs/2026-08-09-loop-mode-poetry-design.md:204

• This section contradicts the PR: src/handler.ts now passes config.weatherLocation into runFetch. Keep the no-new-control-plane-ops statement, but document the actual fetch-path wiring.

### 4.6 `src/handler.ts` — unchanged

No changes. Loop start/stop never reaches the Lambda (§2), so there are no new ops, no `EventBridgeClient` in `InjectedClients`, and no handler-level token check to get right or wrong.

docs/superpowers/specs/2026-08-09-loop-mode-poetry-design.md:303

• This says truncation is unnecessary, but buildFinalMessageForDiscord explicitly truncates an oversized base output and clips or omits an oversized suffix. Since this spec is marked implemented, document the actual cap behavior rather than asserting the opposite.

- **"Reminds me of" message length.** With the `base_message` separation, the suffix is always built from the past tick's pre-suffix text (a single LLM output, ~150 chars), never from a past `formatted_message` that includes a prior "Reminds me of" line. The posted message is bounded at one base + one suffix (~300 chars typical), well under Discord's 2000-char limit. No chain growth, no truncation needed.